High-integrity processing platforms, e.g., flight deck or auto flight platforms, typically employ cross-comparing of computation outputs from two or more processors in order to detect and/or mitigate random faults. For applications such as fly-by-wire, two or more commercial-off-the-shelf (COTS) processors are generally used to compute fault-independent outputs which may be cross-compared to detect potential common-mode errors and random faults. The cross-comparison may be carried out using a bit-for-bit comparison method, or the cross-comparison may be carried out using a threshold comparison method that may allow for small differences in the computation outputs within certain predefined tolerance values.
In view of the expressed preferences of several certification agencies (e.g., Federal Aviation Administration, Transport Canada, European Aviation Safety Agency) to use dissimilar COTS processors and/or algorithms to address the occurrence of random faults as well as arbitrary generic (design) faults, certain drawbacks have become apparent in each of the aforementioned cross-comparison methods. In fly-by-wire applications utilizing dissimilar COTS processors, it may not be guaranteed that bit-for-bit identical results will be obtained from computations, due to round-off errors and/or design choices in the implementations of the COTS processors, despite the processors being designed to follow conventional mathematical standards, such as, for example, IEEE floating point specification. Detailed processors design data that might be used to analytically identify potential differences and/or confirm identical results is generally not available, due to the design data being proprietary to the developers of the processors and/or the supporting software.
Moreover, in fly-by-wire applications utilizing dissimilar COTS processors, a conventional method for avoiding divergence in threshold comparison applications may allow for common-mode errors and random faults to go undetected. Conventionally, a transfer or exchange of data between processors, either in a master/follower or cross-exchange/agreement mechanism, has been used to prevent divergence. Although data is exchanged between fault-independent lanes, this method has been generally permitted by certification agencies, as an accepted bounded behavior has been implicitly assumed or analytically predictable when a lane fault occurs. However, based at least on potential arbitrary design errors or undetectable random faults within either of the dissimilar COTS processors resulting from design choices in the implementations thereof, it has been theorized that data exchanged between lanes may be utilized in a manner that defeats lane independence and fault detection. For example, in an instance in which a design/implementation of one of the COTS processors results in a fault, this consistent exposure of an improper output to the other processor(s) may result in a system failure (e.g., hard-over or misleading data) when combined with any common hardware fault of the other lane.
What is needed, then, is a system and method for maintaining system integrity in flight control systems including redundant computation lanes having dissimilar processors providing minor computational differences, while maintaining fault independence of the redundant computation lanes for safety and certification purposes.